Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mecanismo para preservar mayúsculas en funciones/procedimientos de la biblioteca #190

Closed
fidel-ml opened this issue Jul 22, 2017 · 23 comments
Closed

Mecanismo para preservar mayúsculas en funciones/procedimientos de la biblioteca #190

fidel-ml opened this issue Jul 22, 2017 · 23 comments
Labels
enhancement

Comments

@fidel-ml
Copy link

fidel-ml commented Jul 22, 2017 •
edited by faloi
Loading

Si en la biblioteca del docente pongo un procedimiento llamado MoverALuchoAl_, cuando pasa a bloques queda como "Mover a lucho al" y en el caso de este nombre propio, debería quedar "Mover a Lucho al". No tenemos una forma de indicar que una mayúscula debe conservarse... :(

¿Ponemos algún otro chirimbolo? Onda MoverA*L*uchoAl_ o MoverA-L-uchoAl_...
¿Alguna otra idea?
@faloi
Copy link
Member

faloi commented Jul 24, 2017

A mí me gusta más el *, pero creo que no está soportado como identificador y no sé si sería correcto agregarlo solo para esto.

¿@rodri042?

@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email

@faloi
Copy link
Member

faloi commented Jul 24, 2017

Pero... pero... no es Gobstones-compliant. Qué flexible te estás volviendo. 😜

@afska
Copy link
Member

afska commented Jul 24, 2017

Wooo. Pero el * es el operador multiplicación y el - la resta. No traería infinitos quilombos eso?
Cosas como a := a2*3f() pasarían a ser ambiguas (¿hago a2 por el resultado de invocar a 3f o invoco a a2*3f?)
@foones

Yo usaría doble guión bajo, a costa de no permitir dos parámetros infijos seguidos. A menos que haya una idea mejor

@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email

@faloi
Copy link
Member

faloi commented Jul 24, 2017

Me gusta la última propuesta. ¿Vamos con los apóstrofes?

@afska
Copy link
Member

afska commented Jul 24, 2017

Esa es buenísima! (MoverA'L'uchoA_) Cargo el issue en gs-element-blockly

@faloi faloi changed the title Falta alguna forma de indicar mayúsculas dentro de un procedimiento de biblioteca del docente Mecanismo para preservar mayúsculas en funciones/procedimientos de la biblioteca Jul 24, 2017
@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email •
edited
Loading

@afska afska mentioned this issue Jul 24, 2017
Closed
@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email •
edited
Loading

@faloi
Copy link
Member

faloi commented Jul 24, 2017

No me gusta la del pragma, porque hay que duplicar el nombre. Te lo banco para marcar que es privado y no usar el aux, pero para el nombre me parece redundante y propenso a inconsistencias.

@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email •
edited
Loading

@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email •
edited by faloi
Loading

@faloi
Copy link
Member

faloi commented Jul 24, 2017

Podemos pensarlo como opcional en la próxima versión, pero definitivamente no para ahora.

@fidel-ml
Copy link
Author

fidel-ml commented Jul 24, 2017 via email

@foones
Copy link

foones commented Jul 26, 2017 •
edited
Loading

Seguramente ya descartaron esto (o hay bastante código ya escrito) pero, en lugar de marcar mayúsculas, ¿no quedaría más prolijo marcar la separación entre palabras? De esta manera la capitalización dejaría de servir el propósito de delimitar palabras.

Por ejemplo, usando underscores:
"Mover_a_Lucho_a" -> "Mover a Lucho a"
o quizás apóstrofos:
"Mover'a'Lucho'a" -> "Mover a Lucho a"
o quizás algo como doble underscore (para que un solo underscore se muestre como tal):
"Mover__a__Lucho__a" -> "Mover a Lucho a"

@afska afska added the ready label Aug 3, 2017
@afska afska unassigned faloi Aug 3, 2017
@afska
Copy link
Member

afska commented Aug 3, 2017

Me copa por la versatilidad pero habría que migrar el código ya escrito.

Si optamos por esa quedaría underscore para denotar que ahí va un parámetro, y apóstrofe como reemplazo del espacio. Ejemplo: para mostrar Mover a Lucho (3) metros hacia el (Norte) se podría usar:

Mover'a'Lucho_metros'hacia'el_

Si no, optamos por la de MoverA'L'ucho_MetrosHaciaEl_

@fidel-ml
Copy link
Author

fidel-ml commented Aug 3, 2017 via email

@faloi
Copy link
Member

faloi commented Aug 3, 2017

El pragma me gusta, pero como excepción que pisa a la convención de los guiones bajos. Tener que ponerlo en TODOS los procedimientos me resulta excesivamente molesto.

Mi propuesta:

  1. Si no hay pragma, el nombre se genera como ahora: las mayúsculas separan palabras, los guiones bajos marcan posición de los parámetros.
  2. Si hay pragma, el nombre es el que diga ahí.

@fidel-ml
Copy link
Author

fidel-ml commented Aug 3, 2017 via email •
edited
Loading

@fidel-ml
Copy link
Author

fidel-ml commented Aug 3, 2017 via email

@faloi
Copy link
Member

faloi commented Aug 3, 2017

Ahí sí prefiero el pragma, lo otro fue un hack. Pero abrí otra issue y lo discutimos ahí, así no se mezclan los tantos...

@afska afska removed the ready label Aug 10, 2017
@fidel-ml
Copy link
Author

Surgió la necesidad de tener comas en los nombres de bloques. Esto es imposible con el formato actual, y agregar los tildes para mayúsculas es otro hack no extensible.

Ej: hace falta un procedimiento primitivo "Poner _, _ veces" que hoy no tiene equivalente en Gobstones.

Además, si en bloques hoy usás una coma en un identificador, el código generado hace cosas raras...

Se impone usar un mecanismo flexible que permita interfasear los dos mundos, y hasta ahora la única propuesta que parece razonable es el pragma. Deberíamos ponernos de acuerdo en la sintaxis de los pragmas...

@asanzo asanzo mentioned this issue Sep 20, 2017
Closed
@asanzo asanzo mentioned this issue Nov 3, 2017
Closed
@afska
Copy link
Member

afska commented Feb 23, 2018

Quedó implementado el atributo block_name (opcional - si no está, usa la convención).

/*@ATTRIBUTE@block_name@Poner _, _ veces@*/
procedure PonerColor_cantidad_veces(color, veces) {
  repeat (veces) {
    Poner(color)
  }
}

@afska afska closed this as completed Feb 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@faloi @afska @foones @fidel-ml